Software products that are available on multiple platforms (i.e., cross-platform products) provide larger user bases than single platform products. A software developer generally wants to provide a consistent user experience (i.e., look and feel) across those platforms so a user familiar with the software product on one platform will immediately feel comfortable with the same software product on another platform.
The mechanisms to display content on the screen differ widely between platforms running different operating systems. For example, some desktop operating systems do not include functionality to compose (i.e., combine) content from different applications on the screen. Instead, each application is responsible for creating and updating screen images and having them displayed. While some operating systems provide ways to compose content for display, each has its own unique way of accomplishing this task. The inconsistency requires the software developer to learn how to interface with each different operating system to which the software product is ported.
Beyond simply requiring the software developer to learn platform-specific implementations of graphics functions, the implementation differences may require substantial rewriting of code in an effort to replicate the user experience on different platforms. Each rewrite introduces the potential to introduce new errors and requires additional quality assurance testing. When an operating system does not provide the required functionality or performs the function differently than expected, it may be impracticable, if not impossible, to provide a consistent user experience on that platform.
Even when the functionality is replicated, the application may differ in efficiency and responsiveness among the various platforms. This may result from factors such as the software developer's different levels of familiarity and experience with each operating system, the strengths and weaknesses of the composition functionality available in the various operating systems, and hardware timing constraints.
Historically, in some applications, the user interface thread has been responsible for all functions of the application including applying the application logic and rules, handling inputs to the application, and presenting the application content to the user. The responsiveness of the application is based, at least in part, on how quickly the user interface thread processes inputs and renders changes to the application content. When rasterization is handled by the user interface thread, an application will appear unresponsive if the user interface thread is busy when content updates are needed because rasterization cannot occur until the user interface thread finishes its current task. To deal with the increased processing requirements associated with touch screens, dedicated application threads have been created to decouple the application responsiveness from the code driving the user interface.
Rendering of application content for display is still controlled by the application thread and does not benefit from this divide. If the application thread is busy performing an operation on the application content when rendering is needed, rendering will be delayed until the operation completes. The application may be perceived as being unresponsive if part of the application moves into a portion of the screen that has not been realized (i.e., rendered or updated) yet. This may occur when the application thread does not rasterize the application content within a few frames of the initial touch input. For example, in one operating system, it was noted that applications begin to appear unresponsive if the application thread does not rasterize the application content within approximately four frames of initiating a pan by swiping one's finger. Guaranteeing this level of responsiveness from the application thread at all times is difficult.
These problems continue throughout the life of the software product as updates and patches are developed. It is with respect to these and other considerations that the present invention has been made. Although relatively specific problems have been discussed, it should be understood that the embodiments disclosed herein should not be limited to solving the specific problems identified in the background.